In current Information Technology (IT) environments, software installation is one of several routine tasks. For example, new software needs to be installed, existing software needs to be upgraded to a newer version, and defective software needs to be fixed by software patches. IT departments of various government and business entities need to deal with installation packages for all sorts of software (e.g., inspect, maintain, create, install). Software vendors need to deal with installation packages for their software products as well (e.g., create, maintain).
Differencing different versions of an installation package is desired. For example, in a typical software development environment, a binary installation package may be assembled multiple times from relevant components during development. Each assembly may be called a build. In a typical life cycle for a binary installation package, multiple builds may be generated. Each build may be different from other builds because one or more components may be modified between different builds.
A typical IT environment may keep binary installation packages in a source control system. Also, a source control system may be in a software development environment. A source control system may be a file management system that facilitates one or more users to work on one or more versions of one or more files. For example, after a binary installation package is assembled, a first developer may check out from the source control system the binary installation package, change one or more components and create a new build. If the first developer does not lock the binary installation package for exclusive modification, a second developer may check out from the source control system the same binary installation package, change one or more components and create yet another build. Each build will be different and the developers may need a utility to help identify the differences between the builds to reconcile the differences either when the builds are saved or later when deciding which build may be ready for deployment. The reconciliation may be referred to as merging.
Further, differencing different versions of an installation package is desired for IT departments that need to maintain and/or install binary installation packages. For example, an enterprise entity may have a policy to require that each binary installation package be inspected, and a list of modifications compared with a previous version of the installation package be generated before a binary installation package is deployed to target machines.
However, because each build (e.g., version) of a binary installation package may be a binary image, existing document comparison tools (e.g., WinDiff by Microsoft Corp., DeltaView by Workshare Ltd.) that may compare content of document files may not provide useful information about differences between different binary images. Further, the binary installation package may have different formats under different software specifications (e.g., Red Hat Package Manager (RPM) for a Linux operation system, Microsoft Installer (MSI) for a Windows operating system) that may make one solution to one binary format inapplicable to a different binary format.
One approach of solving the issue has been to generate a text file (e.g., XML file) for each binary image and use the existing document comparison file to compare the content of the text file. The problem with this approach is that the comparison only shows literal differences between two text files, not underlying differences between two builds of a binary installation package. Further, generated text files may lose details of the differences between two builds of a binary installation package and also increase the complexity of an installation tool. For example, an installation tool taking this approach may generate an XML file for each build. The generated XML file may not gather all information inside a build, thus may lose details of the build. Moreover, if this tool does not sort the content of the XML files in the same way on each build, differencing the XML files only shows the literal difference that may be due to the order of content, thus making it hard to find the real differences in different versions of a binary installation package.
Another approach has been to use a grid based table and perform a row by row differencing using the grid based table. For example, a Windows MSI package is a standard installation package for a Windows operating system. An existing technique of differencing two Windows MSI packages uses grid based tables. That is, a user may select a table from each MSI package and compare the tables to show differences between the two packages (e.g., a row by row comparison for additions, deletions, or modifications). However, there are many tables (e.g., File, SelfReg, Component, Directory, Feature, Feature_Component, Registry) in an MSI installation package. Properties related to entities (e.g., a file), may be scattered into many tables. Thus, the value of one property of a file (e.g., size of the file) may be stored in one table (e.g., File table), while the value of another property of the file (e.g., installation location) may be stored in another table (e.g., Directory table). Therefore, a row by row comparison of grid based tables (e.g., File table) won't show the relationship between the changes in multiple tables or the impact of a change in one table on another table, thus makes changes difficult to interpret. Further, a comparison of grid based tables will not show the nature of the differences between two versions of a binary installation package.
In view of the foregoing, it may be understood that there are significant problems and shortcomings associated with current binary installation packages differencing technologies.